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The information contained in this document relates to Prestel Pubiic Service 
version 46. 


NOVEMBER 1981 


SECTION 1 INTRODUCTION 


The Prestel System offers two independent methods by which an Information Provider 
(IP) may update the database. The 'online editor' is used by an IP keying 
information directly into the system from a standard viewdata terminal and 

editing keyboard. 'Bulk Update' is used where the input data is supplied 

to Prestel by another computer system, or by a microprocessor-based intelligent 
editing terminal. 


Although the two input methods are independent, a substantial part of the 
processing performed by the Prestel system is the same for both types. In 
particular, input data for both systems is subject to the same security and 
integrity checks. 


This document describes the formats and protocols require for Bulk Update. 
A working knowledge of the Prestel system and the online editor is assumed. 


At present, two different input media are available to Bulk Updaters: 

Magnetic tape batch update, with reports output to a line printer; 

On-line update via a telephone line, using an asynchronous protocol. 
It is planned in the future to introduce in addition a synchronous on-line 
protocol. This will use the IBM 'BSC' protocol, as defined in the IBM reference 
manual 'General Information - Binary Synchronous Communications' GA27-3004-2, 


The GEC implementation of the protocol which will be used by the Prestel system 
is described in the GEC manual 'Synchronous Communications' DD1306. 


SECTION 2 RECORD TYPES 


1 This section describes the record types available to the Bulk Update 
user. Detailed input record layouts are at Appendix B, with explanatory notes 
at Appendix A. A copy of the viewdata character code table is at App F. 


2 It should be noted that the records are processed serially - the database 
is updated by each record in turn. The IP must ensure that the records appear 
in a valid order; for example, a page may not be deleted while any filials 
exist. 


RECORD TYPES 


3 RUN HEADER/LOGON RECORD The first record of a run (magtape or online) must 
by a 'logon reguest', to identify the IP to Prestel and enable his file data 
(logo, CUGs etc) to be accessed. The record contains the following information:- 


3.1 USER ACCESS CHECKS The record contains a systelno and an editing 
password identical to the current password used by the IP for online 
editing. If the run header is not the first record, or if the systelno 
or editor password are invalid, an appropriate error message is output 
(see App C) and the bulk update run is stopped. 


3.2 OUTPUT IDENTIFICATION (MAGTAPE ONLY) The record also contains a 
name and address which are printed on the first page of the output report. 


3.3 ONLINE UPDATE. If the 'reply wanted' indicator was set on the 
input record, a full 'logon reply' is transmitted to the IP's computer 
(format at App C page 1), otherwise a standard 'update ok' (ie a '0') 
is transmitted. 


4 BATCH HEADER (MAGTAPE ONLY) This signals the start of a batch of update 
records. 


5 BATCH TRAILER (MAGTAPE ONLY) This signals the end of a batch of update 
records, and contains counts of the number of records in the batch. 


6 UPDATE RECORDS These records are used to update the framefile on the 
database. The six data types available are: 


6.1 INSERT FRAME This record is used to enter a page or frame (eguivalent 
to the 'enter' option in the online editor) and therefore contains the 
appropriate fields ie page number, frame-id, cugs, frame type, price, 
routeing choices and frame contents. 


6.2 REPLACE FRAME TABLE THis record is used to amend an existing frame 
(equivalent to the 'overwrite' option in the online editor) and contains 
the same fields as 'insert frame' (para 6.1). 


NOTE: The frame contents field may be omitted in this record, thus amending 
only the frame control information, and leaving the displayed information 
unaltered. 


6.3 REPLACE FRAME This record is used to amend only the displayed part 
of an existing frame (eguivalent to the 'amend' option in the online 
editor). It contains an identifying page number, frame identity and 

the frame contents field. Note that the frame contents are completely 
replaced by the new version - there is no facility to supply amendment 
data only. 
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6.4 DELETE PAGE This record is used to delete all the frames of a page 
(equivalent to 'delete page' option in the online editor). It contains 
just an identifying page number. 


6.5 DELETE FRAME This record is used to delete the last frame of a page, 
ie frame identity b-z (equivalent to 'delete frame' option in the online 
editor). It contains an identifying page number and frame identity. 


6.6 REINSERT FRAME This record type, for which there is no equivalent 
in the online editor, acts as a 'replace frametable' (see 6.2) if the 
frame already exists on the database, or as an 'insert frame' (see 6.1) 
if it does not exist. š 


RETRIEVE FRAME This record contains a page number and a frame identity, 


and results in a frame being retrieved from the database. Only the IP's own 
frames may be retrieved in this way. 
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7.1 MAGTAPE UPDATE The frame and its control details are printed on 

the output report. Control characters are not printed and graphics characters 
are replaced by '*'. Only 30 such records are allowed in a batch, any 

extra ones being ignored. 


7.2 ONLINE UPDATE The frame and its control information are transmitted 
to the IP's computer in the format shown at App C page 3. 


MESSAGE CONTROL RECORDS (ONLINE ONLY) 


These record types are used to retrieve message/response frames or send messages 
to other IP's, eguivalent to the facilities available on pages 930 and 931 in 
the online user system. 4 record types are available: 


8.1 RETRIEVE NEW MESSAGE. This results in the transmission of the first 

new message to the IP's. computer, (layout at Appendix C). If no new 

messages are available, an error code is sent (Appendix D4). Note that if 
the next record is neither a STORE MESSAGE nor a DELETE MESSAGE, this message 
remains the first new message, so another RETRIEVE NEW MESSAGE will get 

the same message again. 


As for the online user system, a charge is made for message retrieval. 
At present, the IP's frame charge total is incremented by 3p for each 
new message retrieved. 


8.2 RETRIEVE STORED MESSAGE. The first such record retrieves the first 
stored message, and subsequent records retrieve the following stored 
messages in turn. It is not necessary explicitly to re-store a message 
having retrieved it, but no error occurs if this is done 


8.3 STORE CURRENT MESSAGE. This record type is only valid immediately 
following a RETRIEVE MESSAGE (NEW or STORED) , and results in the current 
message being stored. 


8.4 DELETE CURRENT MESSAGE. This record type is only valid immediately 
following a RETRIEVE MESSAGE (NEW or STORED), and results in the current 
message being deleted. 


RUNTRAILER/LOGOFF RECORD This record termínates the run. 


9.1 MAGTAPE UPDATE. The Run Trailer record contains a count of the 
number of batches expected. A summary report is printed and the run 
terminates. 


9.2 ONLINE UPDATE After receipt of this record, a 'logoff reply' (see 
App C) is transmitted and the telephone connection broken. 


SECTION 3 MAGNETIC TAPE UPDATING 
1 This section describes the requirements of the magnetic tape batch updating 
system. Detailed record layouts are given at Appendix B, with explanatory 
notes at Appendix A, and a list of error messages which may appear on the 
output report is at Appendix D. 
MAGNETIC TAPE FORMAT 
2 CHARACTERISTICS The tape used must have the following characteristics: 
' 2.1 NRZI mode; 

2.2 Nine track; 

2.3. 800 bpi; 

2.4 No coupling; 

2.5 Reel size between 6 in (200 ft) and 10.5 in (2400 ft). 


3 TAPE LAYOUT: Data is arranged on the tape in the following layout: 


' | i | | W 
| IR s | DN B|B aja] 
| IU A | AIA; A| A EFE 
NT] ENE rl T (E | 
B C. cic | cial CET 
| | | [H| BATCH ESES sin dE TAPE 
TAPE iH | OF T |H |FURTHR| T | H BATCH |T | AJ MARK 
| | MARK | E | H | UPDATE HE BATCHES| R| E | JL | (2) 
ú (1| ¡A | El RECORDS | A A ES ajul | 
| EJES LoD | Ij D: LIE | 
|| | IE|D; EA KI E| L|R| | 
| | AER | E.R | E|R. IE) d | 
| Í |i 48 R | R | R | 
| | | 


3.1 IP LABELS (optional). These are included for compatibility with 
other computer systems, but have no significance for Prestel. All data 
before the first tapemark is ignored. 


3.2 TAPEMARK (1). Signals the start of the user data. 


3.3 TAPEMARK (2). Signals the end of the user data. No attempt is made 
to read beyond the second tapemark. 


4 BLOCK LAYOUT The user data records are held in blocks in the following 
format (IBM RECFM=VB): 


n l 
Block header i record | record | | record 


! | 
l i 


4.1 The block header consists of 
2 bytes - block length (including block header) 
2 bytes - block number 


Both fields are held as binary numbers. If a block is read out of sequence, 
the run is halted. If the blocknumber field contains zero or spaces, 
block number checking is not performed. 


4.2 The maximum size of a block is 3000 bytes. A record may not be 
split between two blocks. 


5 BATCH CONTROL Data records must be grouped into batches of not more 

than 100 records, by use of batch headers and trailers (DTs 03, 04). Any 
records over the maximum are ignored. A separate count is kept of DT31 (print 
frame) records; only 30 such records are allowed in a batch. Any records 

not preceded by a valid batch header are ignored, and if the first record 
following the run header is not a batch header, the run is terminated. 


At the end of a batch, counts of each record type are compared with the 'expected' 
figures from the batch trailer. If they do not watch, a warning message is 
printed, but the run continues. 


OUTPUT REPORTS 


6 A printed report ís produced listing all batch headers and trailers and 
identifying any erroneous data records. The IP's name and address from the 

run header record is printed on the first page of the report. A summary is 
printed at the end of the report identifying the number of records read, number 
of errors found, and the net change in the number of frames on the IP's database. 


7 In addition to the printed reports, a series of message frames is generated 
and sent to the IP, containing all the information from the printed report 
except the name and address and 'retrieved frame' prints. The system will 

not attempt to generate more than 20 such message frames ín a single run, 


SECTION 4 ONLINE UPDATING - ASYNCHRONOUS PROTOCOL 


1 This section describes the requirements of the asynchronous protocol 
used for online bulk update. Detailed input and output record layouts are 
given at Appendices B and C, with explanatory notes at Appendix A. Reply 
codes are listed at Appendix D. Telecom requirements are set out in Appendix E 


ASYNCHRONOUS COMMUNICATIONS PROTOCOL 


2 TRANSMISSION CHARACTERISTICS. The basic transmission characteristics 
are as follows: 


2.1 300 baud (Datel 200) 
or 1200 baud (Datel 600); 


2.2 Half-duplex mode; 
2.3 1 start bit, 1 stop bit; 
2.4 Even parity; 


3 CALL SET-UP. The facility is accessed via the switched telephone network, 
by calling the appropriate bulk update number, depending on the speed required. 
The call is answered automatically, and a carrier tone is heard. The tone 
remains for 10 seconds, during which time the IP should establish the connection 
to his computer. At the end of the 10 seconds a '1' block is transmitted 

by the Prestel system, which is then ready to receive the first record 

(ie the 'logon request'). If the logon request is transmitted by the IP before 
the end of the 10 seconds, no harm is done, as the 'l' block will be recognised 
- by the IP's computer as a negative acknowledgement (see 5.1 below), and the 
logon reguest will be automatically retransmitted. 


4 CALL PROGRESS. Having established the call, the dialogue proceeds with 
the computers sending alternate messages as follows: 


UPDATE RECORD 
RETRIEVE REQUEST | 


ERROR/SUCCESS CODE 
RETRIEVED FRAME/MESSAGE 


etc 


5 BLOCK FORMAT To minimise the effect of transmission errors a record 
is split into blocks of a smaller size which are transmitted separately and 
re-assembled at the receiving end. The maximum size of a transmitted block 
is 80 bytes. The format is as follows :- 


PAD SOH TAG STX «data» «term ><bcc> US 


where PAD is any non-significant character; present for timing purposes only, 
ignored by the receiving machine 


SOH 'identifies the position of the TAG character 


TAG is used for diagnostic purposes. It takes the value '0', 'l', 
--- '7', '0' — etc on successive blocks transmitted. If a 
block is retransmitted because of a timeout, TAG is not 
incremented. This enables the receiving computer to detect 
missing or repeated blocks. 


Note: in the current Prestel version, the SOH and TAG characters are 
generated on all output blocks but not checked for on input. 


STX identifies the start of the data. 


¿< data» is the information part of the block; 
maximum length 75, minimum length 0 


4term» is the data terminating character; 


ETX if this is the last block of a record; 
ETB if more blocks for the same record follow; 


<bcc> is the block check character, formed by performing an 'exclusive 
or' operation on all the characters following STX (horizontal 
parity check). The parity bit itself is not included in the 
horizontal check, but is set so as to make the bcc itself have 
even parity. 


US is the unit separator character required as a block terminator 
by the software. If the bcc character happens to be a 'US', 
the final 'US' must be omitted - ie only one US is allowed in 
any one block. 


5.1 Receipt of a block is acknowledged by a block of the same general format 
whose «data» field is a single character as follows: 


O means the block was received correctly (but see 5.2 below); 


1 means that a parity or bcc error was detected - the block must 
be retransmitted; after 12 such retransmissions, the call is abandoned. 


3 means that the actual length of the record is not as specified 
in the 'record length' field, or that the record is too long 
for the input buffer (can be the result of transmission errors). 
The whole record should be retransmitted. If a '3' is received 
in response to an ETB block, the record must be terminated 
before it is retransmitted, by sending an ETX block, which will be 
acknowledged by a '3'. If this is not done, Prestel is unable to 
distinguish the retransmitted record from the previous one, and will 
therefore give a '3' reply to the retransmission as well wnen the 
ETX is eventually received. 
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5.2 Positive acknowledgement of the final block of a record (ie one 

terminated by ETX) is neither required nor expected; it is in fact implied by th 
transmission of the next record, which will normally be an update success 

or failure code from the Prestel computer, or another data record from the 

IP. If an acknowledgement ('0') block is sent under these circumstances, 

it is treated by Prestel as if it were a new data record, and failed 

with code 3 (record length error). 


TIMEOUTS To guard against the possibility of a block being lost in transmissior 


a timeout ís applied after each block ís sent. If no return message is received 
within the timeout period, the block is retransmitted. If no reply is received 
after 12 such retransmissions, the call is abandoned. The timeout values currently 
applied are (approximately): 


6.1 after transmission of ETB block: 2 seconds 


6.2 after transmission of ETX block: 10 seconds 


To avoid the possibility of both computers timing out and retransmitting at 
the same time, the IP should employ different values - say 4 and 12 seconds. 
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ERROR CONDITIONS 


7.1 Under conditions of heavy load, it is occasionally possible for 

a retransmission to occur when no transmission loss has actually occurred; 
this can result in a block being received twice. In such a case, the 
'record length' check which is applied after receipt of the ETX block 
will detect the error and result in the whole record being sent again. 


A similar record length check should be applied by the IP on receipt 
of a retrieved frame or message (DIs 03, 04, 05). If the check fails, 
retransmission must be requested by sending again the original request 
(DT 31, 41, 42) rather than by sending simply a '3'. 


7.2 In some circumstances it is possible for the IP to treat Prestel's 
retransmission of a block as if it were the reply to a new request from 
the IP. This is particularly unfortunate if the records involved are 

a 'retrieve frame' request from the IP and a 'page/frame does not exist' 
from Prestel. The use of the TAG character (see para 5) should assist 
in detecting this situation; alternatively, it may be found prudent for 
the IP's computer to retry automatically every failed 'retrieve frame' 
reguest. 


7.3 If an invalid block is received in reply to an ETB block (when 

'Q', 'l' or '3' is expected) it should be ignored: if it was pure noise, 
the 'real' block will arrive soon, if it was the 'real' one, but corrupted, 
the timeout mechanism will arrange for retransmission. 


If the block received in the same situation is not invalid but unexpected 
(ie not a '0', '1' or '3'), it should be treated as a '0': any other 
reply is likely to involve further retransmissions followed by loss of 
the call. 
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Appendix A 


Sheet 1 
PRESTEL BULK UPDATE 
NOTES TO RECORD FORMATS 
1 This Appendix explains the various codes and symbols used in the record 


layouts in Appendices B and C, and also describes the contents of the various 


fields. 


Some record types are applicable to both online and magtape update - these are 
headed 'BULK UPDATE' - whereas others are headed 'MAGTAPE UPDATE' or 
'ONLINE UPDATE' as appropriate. 


COLUMN HEADINGS 


2 POSITION. These columns define the position of the field in the record. 


3 FIELD-NAME. Describes the contents of the field. 


4 PICTURE. Describes the format of the data within the field. The codes 
used have the following meanings: 


ZN = 


SN = 
A = 
AN = 
V = 
5 SIZE. 
6 OCCS. 


numeric characters, right-aligned, zero-filled. An unused entry 
(eg in the CUGS field) consists of all zeroes or all spaces. 


numeric characters, right-aligned, space filled. An unused entry 
(eg an 'invalid choice' entry in CHOICES) consists of all spaces. 


Upper or lower case alphabetic character (not space) 
Upper or lower case alphabetic, or numeric character. 


any viewdata character except cursor controls (ie columns 0 & i 

of the code table) but including ESC, CR, LF. The FF (clearscreen) 
character is also allowed, but only for the specification of response 
frames (see 11.5 below). In addition the characters SI, SO, SS2, 

SS3 are acceptable; they are reserved for use with specialised 
terminals in the specification of alternate character sets. 


Shows the size of the field in bytes. 


Shows the number of times the field is repeated. 


FIELD CONTENTS 


7 RECORD LENGTH, All record lengths are inclusive o£ the record length 

field itself. For magtape records, the field consists of two subfields: 

the first two bytes hold the length in binary, the second two bytes are ignored. 
For on-line records, the format is ZN - a four digit decimal number. 


8 CUGS 


8.1 USER ACCESS. This corresponds to the 'user access' prompt in the 
online editor. A value of Y or space signifies that all users (subject 
to CUG check) may view the frame, while a value of N means that only 
the IP himself may access it (regardless of CUG checks). 
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8.2 CUG. Any frame may be placed in any CUG which the IP owns, by quoting 
the appropriate 5-digit CUG number. If the field is all spaces or all 
zeros, the frame is placed in CUG number 2 (the 'null CUG'), to which 
all users have access. This value will also appear in a 'retrieved frame’. 


CHOICES. The ten choice fields denote the page numbers to be selected 


when the user keys the digits 0-9 respectively. If any choice field is left 
blank, the choice is invalid, and the user will receive the 'SORRY NO SUCH 


PAGE! 
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response. 


FRAMETYPE, Upper or lower case alphabetic; I, i or space denotes an 


information frame, A, a, R or r denotes a response frame. 
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FRAME CONTENTS 

11.1 A line of data displayed on a viewdata screen consists either of: 
a. exactly 40 displayed characters; or 
De less than 40 characters, terminated by CR LF characters; or 
C. a blank line, consisting of CRLF, or LF alone. 


11.2 The 'frame contents' field consists of up to 23 such lines. The 
first line of the input data is always replaced by the standard Prestel 
line 1 (IP logo, page number, price). The top line may be represented 
in the input record by the minimum length line CRLF, or just LF. Any 
data beyond the 23rd line is ignored, as the Prestel system uses line 
24 for system messages to the user. 


11.3 Every viewdata control character (columns 4b and 5b of the code 

table) is identified by being preceded by an ESC character. The control 
character itself occupies a single position on the screen, but the ESC 

does not, so a data line input to the bulk update system may contain 

more than 40 actual characters, provided that the number of displayed 
characters (ie excluding ESC) does not exceed 40. However, the total 

space available within the system for storing a frame including ESCs, 

is 920 characters for an information frame or 716 characters for a response 
frame. Line 1 occupies at least 43 characters (depending on the number 

of control characters in the IP's logo), so the space available for an 

IP's data is 877 characters at most. To make the most of the space available, 
the Prestel system 'optimises' the frame contents by removing spaces 

at the end of lines, replacing them by CRLF characters. If the frame is 
still too long after this optimisation, any excess characters are ignored. 


11.4 The only cursor control characters which may appear in the 'frame 
contents' field are CR LF. If any other cursor controls are present, 
or any other invalid characters, they are replaced by DEL characters, 
which appear on the screen as a white box. If this occurs more than 
20 times on a single frame, the record is rejected (code V, see App D2). 


11.5 RESPONSE FRAME A dialogue field is signalled by a 'clearscreen' 
character (HEX'0C') followed by a permissible dialogue character (lower 

case a-z). This is then followed by any number of the same dialogue 
character; the end of the field is signalled by the first occurrence 

of any other character. The 'clearscreen' character becomes the 'privileged 
space' and the dialogue characters define the dialogue field. The standard 
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dialogue characters eg 'n' (name), 't' (telephone number) 'd' (date and 
time), 'a' (address) have the same special significance as for the online 
editor, and free format fields (to receive user data) are denoted by 

any other permissible dialogue character - conventionally VES Q 
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Sheet 1 
Record name MAGTAPE UPDATE — RUN HEADER ñ 


Max length 465 bytes 


Mä Lem | ses | [sio coa es | 

Froml To | Field-name 

mm lans ve | | see noted la | | = 165 

alo] mmm || mo [lo] jon | 
)Spaced and edited tc 

| jsis|mmms || + |o | atten mon o se 
printed as a 6 line 

llas los lems anza || wv [po | | fence tor sse with 
)window envelope 

Kei sms |l Y 2 do return edass 
)report to the 

nal. ^> L m el EUR 


BASE 2 
[res pas | mr Passion er pel | | 
EP printed at the head f 
"ERR — UR E ere 
" can be used by the I 


Not MAGTAPE UPDATE ONLY 


See Appendix A for notes 
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Record mam ` MAGTAPE UPDATE — RUN TRAILER R | 


Max length 10 bytes 


| eme mas [| peure | [sau] can [nous 

haen | sd Lol E —] 

als [mowes || a [|a] Le 

RAD —— NEN : KON PT AR ARN 
MEME 


MAGTAPE UPDATE SS 


See App A for notes 
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Record name ONLINE UPDATE — LOGON REQUEST 


Max length 20 bytes 


Position 
B CIERRE 
[tots | sso vam La zssi Ja | Leen. 
| ja|s|smom mm || zm [le] [eon | 
| > || m llol |. | 
| [o | Twm _l| ae llo [wenol 
his lio | mr zen La pel pp — 


REPLY WANTED determines the type of reply wanted if logon is successful: 


: a simple "0" reply code is sent 
: a full message (as in App C Sheet 1 
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Record name On INE UPDATE = LOGOFF REQUEST 


Max length 6 Bytes 


Position 
Froml To Picture 
lola | mom mom | = ||. | ans 
TT: | mom wees | aÜ die] lar | 


ONLINE UPDATE ONLY 
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Record name MAGTAPE UPDATE — BATCH HEADER 


Max length 10 bytes 


| [erom Te Le PIPA 
f From| To Notes 
min som see JL 
LI lees sms || zm sl few o | 
| tel lann moe | | om JI" 
fit. T HS T | 

NE 


MAGTAPE UPDATE ONLY 


See App A for notes 
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Record name ` MAGTAPE UPDATE — BATCH TRAILER 


| rromi To ans L ses | jS | oces [Wows 
Froml To Occ: | Notes 

[fos [mom imo EE 
Tse ms [L =» [E| [e | 
TS ms a e 

o fe [eos com — [| [b fr [i-maan | 
L O ETT 
ill]... 7] || | EN CE 
HAHAHA 
III || H | EEE 
411... AO] rre 


llTT7 H Y A IES 


Notes 


MAGTAPE UPDATE ONLY 


See App A for notes 
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Record name 


BULK UPDATE - REPLACE FRAMETABLE : R 


Max length 1080 bytes 


Mä Les | | ses [salon we 
From| To Picture 

| ofa keem senora | [see notes] Ja | | | 
IJ: keem mme a pl bo | 
Lei ke mom Us [lo | Po | 
| j| ken weem | a UI (eco | 
[lm] ken spe. |l x Uh hem benwan 
lel la een 
HARÁ 
llas susmi 

32 135 |FRAMEPRICE ZN 4 pence, max 50p 

Mm” | a Ilo | | | 
S bel [eza [la dl] to | 
[ Jl kees covens LI: | | wenn | 


1. See App A for notes 


2 If the FRAME CONTENTS is not present (RECORDLENGTH = 127 or 128), only the 
frame table information is amended. If only a single byte is present after the 
FRAMETYPE field, this is not deemed to constitute a frame. 

If the RECORDLENCTH is 129 or 130, the frame contents are cleared to spaces. 
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Record name BULK UPDATE — DELETE PAGE 


Max length 15 bytes 


== Tas on Te 

From| To | Fieic-name Notes 
DDC fem | |n.” | 
MODE Ta tel ee 
Deep 11 | | 


Notes 


See App A for notes 
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Record nama ` yir K UPDATE - INSERT FRAME 


Max length 1080 bytes 


B to dman | | ses Les ës [nome 
Froml To 

| o| s kee | bee notes} [8 | | | 
fels ken ze [| as [fo] enn 
M——— 
| s] kees zess ° || a Tila | [Were or tower cast 
lis) maes | la lan tor spacenyes d 
[s aja — Ia ||s | fae | 
dajale LI II 
e [as [raeno Ja IT Er 
las los Leen LL sw tLe fo | | 
Lla] mem || a ho | 
| ber | lag comers || II: 


Notes : 


See App A for notes 
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Record name 5ULK UPDATE — REPLACE FRAME 


Max length 976 bytes 


Es L Son 1 P eg... 
From To |Fieid-name Oces | Notes 
PL rom ma Usel: | C À] 
pere] a [e| [ee 
MUTE PAGE NUNBER EE 
= Upper or. lower case 


Notes 


See Aon A for notes 
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ee name BULK UPDATE — DELETE FRAME n 


Max length 46 bytes 


B To (riwénme || ses | |s| oces wm | 
Froml To 
mH Y e eg 
| fats Lee ems Is [fe] |n | 
llenn ll E ess 
| [5| Lee zem ` || a Ui re 


Notes 4 


See App for notes 


To delete frame tat, record type 12 must be used 
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Record name 
BULK UPDATE - RE-INSERT FRAME n 


Max length 1080 bytes 


EE — a] 

Sc umm 17 P9 EE 
ENE let CO 
pedem sm L= [EL F _ 
ROET — |l» JLI — — 
Homes ee O [>| mn 
BESSEREN RSC 
am HE 
i [alnlnamn La HESE 
Cell — 1 = US 
Da mama ll. lll 
hal [rae cores ll JH |} | 


Netes ; 


See App À for notes 


This record will replace an existing frame, or act as an 'insert' if the frame does 
not exist. 
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Appenaic 5 
Sheet 13 


Record name — BULK UPDATE-RETRIEVE FRAME 


Max length 16 bytes 


Position 
Froml To 
ENEE EHO IEC 
la ls | om ms | a [tel fem | 
EHnPTT |» [lol] | — 1| 
Upper or lower case 
15 FRAME IDENTITY A 1 alphabetic 


See App A for notes 
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Appendix B 
Sheet 14 


Record name 


ONLINE UFDATE-RETRIEVE NEW MESSAGE 


Max length 6 bytes 


— 

Erol To Cees |Notes 
Sa Tal | ms 

| |a|5 | mom mrs | e [fol |» O 


Notes 


ONLINE UPDATE ONLY 
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Appendix 3 
Sheet 15 


Record 
namS ONLINE UPDATE-RETRIEVE STORED MESSAGE 


Max length 6 bytes 


Position 
Froml To | Field-name 
Tels l eoo mom L| m || [ew | 
| |+ |5 lee mes [ICON IER — 


ONLINE UPDATE ONLY 
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Appendix 3 
Sheet 16 


Record name ONLINE UPDATE — DELETE MESSAGE 


Max length 6 bytes 


A (Se eee 
From| To | Field-name Notes 
MONET | zw [la | Lego 
TTS Tea ms || m E je 


ONLINE UPDATE ONLY 


1 This record must be immediately preceded by either RETRIEVE NEW MESSAGE 
or RETRIEVE STORED MESSAGE and will apply to the mesaage just received. 
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Appendix 3 
Sheet 17 


Record name ONLINE UPDATE — STORE MESSAGE 


Max length £ bytes 


| Position 
Fromi To 
[o e ms REES RER RRE 


Notes ONLINE UPDATE ONLY 


1 This record must be immediately preceded by either RETRIEVE NEW MESSAGE 
or RETRIEVE STORED MESSAGE and will apply to the message just received. 
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Appendix C 
Sheet 1 


Record name ONLINE UPDATE — LOGON OK REPLY 


Max length 74 bytes 


im ss LL see | [sa] oe Je o 
Fromi To 

| jo|s|smmems Ia le] [emo 
| jas] mms moso || a [a | | | 
| jo[m|semsum a sd 
— e H-——H- m 
Lala s — || z [js] Iess ` 
eppen L= TF L 
s a [mao — O EEES 

NN CRW 


Notes 


This message is sent in reply to a logon request record with REPLY WANTED set to 1. 
The IPLOGO is in a similar format to the *frame contents! held on other records 


a every control character is preceded by ESC 


b A line is either 24 non-ESC characters or fewer characters terminated 
by CRLF 
c LOGOLENGTH includes ESC and CRLF characters 
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Appendix C 
Sneet 2 


Record ame ONLINE UPDATE — LOGOFF REPLY R 


Max length 48 bytes 


| [erom To ras || ses | [sa| cvs we | 
Froml To 

loli lees Lal [s | 
lla lo [mem sees || zm lls | | 
| to fir [sma |] alle [| — y 
helas I| > lle] E 
sha U m llad m i 
o bs mora — || [le] em ma ən | 
Ck eem L= JL 1 17 95. 


42 ]47 | NET CHANGE (in size of IP's 


RR TL TT database) 


1 If FRAMES USED is greater than FRAMES ALLOCATED, the system manager is 
informed. 
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Appendix C 
Sheet 3 


Feed a ONLINE UPDATE - RETRIEVED FRAME 


Max length 1120 bytes 


EE eT 

eri H 
Ces HL Hm 

BD T T WEE E I HAEN 
ls meme a lhll — 
Cx mem ll Tia] 
Cue  |s|lbll — 
ps ale — 1 111 U as] 
Tal ale cae m | («| |e enc ota rom | 
[of laces comm tt = [fe] | | 
[apo ll» [EI Pe — o 
dlm CI |l] Tee — 
BE EA L 
[a mem __ ll» IP] | EN 
sepes ||» TP 
pss e ll» lll 
fd ese TL ||] sees — 
HATE 
8 O II T E T SS IEA 
IU II T 11117 7. 
TLC IS O ES 
UU DI TH TT T — 
JII — J HII — 
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Appendix C 
Sheet 4 


Record name ONLINE UPDATE - RETRIEVED MESSAGE 


Max length 948 bytes 


ene H | ses | [sol oes wn | 
Froml To 
[oli ana re [|  ||o| Lossen | 
Lem Ms Tet | 3 
Ls AO 
MEC e [| = s| [mw 
eee 1 O [=== —3 
eee 1 1^9 — —1 
e [ee 1D [[ [ gem — 
CR WS |] 


See Response Frame Facility, IP Manual 


REPLY TYPE '04' - new message 
'05' - stored message 


DATE AND TIME are of sending (new message) or magn (stored message) 
NOT of retrieving 
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APPENDIX D - UPDATE MESSAGES 


ANNEX 


Note: 


1 


2 


LOGON FAILURES 

UPDATE FAILURES 

BATCH CONTROL REPORTS (MAGTAPE ONLY) 
MESSAGE CONTROL FAILURES (ONLINE ONLY) 


TRANSMISSION REPLIES (ONLINE ONLY) 


for MAGTAPE, the whole message is printed 


for ONLINE, the single character code is transmitted. 
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APPENDIX D 


ANNEX 1 - LOGON FAILURES 


RUN HEADER MISSING 


UNKNOWN USER 


INVALID PASSWORD 


SYSTEM FULL 


Run header/Logon request 
record missing 


Systelno in Runheader/Logon request 
record invalid 


Password in Runheader/Logon request 
record does not match entry in userfile 


The maximum number of Bulk Updaters 
are already logged on 


| 9 SYSTEM CLOSED | 


NOTES 


1 MAGTAPE; after any of these messages the run is halted. 


2 ONLINE; after any of these messages the line is cleared and a new call 


awaited. 
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APPENDIX D 


ANNEX 2 - UPDATE FAILURES 


Hv = 


NOTES 


1 


INVALID RECORD TYPE 
PAGE ALREADY EXISTS 
' PARENT DOES NOT EXIST 
PAGE DOES NOT EXIST 
FRAME ALREADY EXISTS 


DISC ERROR 
NOT LAST FRAME 


FRAME DOES NOT EXIST 
PRIVATE CUG 


NOT END PAGE 

FRAME ALLOCATION EXCEEDED 
INVALID PAGE NUMBER 
INVALID FRAME IDENTITY 
UNAUTHORISED ACCESS 


MASTER PAGE 
INVALID FRAME TYPE 


INVALID CUG 
INVALID CHOICE TABLE 
INVALID FRAME 


INVALID PRICE 
TOO MANY DIALOGUE FIELDS 


INVALID DIALOGUE CHARACTER 


do not cause the run to halt. 


Attempt to insert existing page | 
Attempt to insert 'orphan' | 
Attempt to update non existent page | 

I 


System failure - inform Prestel Operations | 
Attempt to delete a frame which is 

not the last of a page, or insert one 

whose predecessor does not exist. 


accessed via a dedicated circuit 
(International service only). 

Attempt to delete a page which has 
filial(s) 

Frames in use exceeds frames allocated 
(for this IP). Further attempts to insert 
new frames are rejected. 


| 
Frame is in a private CUG and cannot be x 


Includes attempt to use dt 23 to delete | 
frame 'a' | 
Attempt to access a page not owned by | 
this IP 

Attempt to delete a master page | 
Includes attempt to set up response | 
frame by an IP who is not allowed to 
Includes attempt to quote a CUG not 

owned by this IP, or invalid 'USER ACCESS' 
field 

Contains non-numeric characters 

Frame contains too many invalid 

characters 

> 50p (999p for international system) 

> 24 fields on a reponse frame 

First character after 'clear screen' is 
not in range a-z 


—— 


These are output in response to invalid updates to the Framefile but 
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APPENDIX D 


ANNEX 3 - BATCH CONTROL REPORTS (MAGTAPE ONLY) 


MESSAGE 


ABANDONED - NO BATCH HEADER 
BATCH HEADER MISSING 
- FOLLOWING RECORDS IGNORED 


TOO MANY RECORDS IN BATCH | 
- EXCESS IGNORED | 


BATCH TRAILER MISSING 


BATCH nnnn RECONCILIATION OK 


BATCH nnnn RECONCILIATION FAILED 


RUN TRAILER MISSING 
BATCH COUNT OK 


BATCH COUNT FAIL 


NOTES 


1 These reports only apply to magtape batch update. 


The first record after the run header | 


is not batch header. The run is halted. 


A data record has been read 
without a preceding batch header. 


À batch header or run trailer record 
has been read without a preceding 
batch trailer. 


Where nnnn represents the batch number. 


This is followed by a report of the 
figures expected and found. 


This is followed by a report of the 
number of batches expected and found. 


Except where stated 
batch control failures result in a warning message only, and do not halt the run. 


2 A number of statistics are printed at the end of a run, whether the 


reconciliation is successful or not. 


IP's frame allocation and usage; 


These consist of: 


Number of record processed and number rejected; 
Net change in the number of database frames used by the IP. 
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APPENDIX D 


ANNEX 4 - MESSAGE CONTROL FAILURE (ONLINE ONLY) 


No more messages to retrieve 


the message due to a system 


| | 
(Hex '5B') can't save/delete/send | 
i 
| 
failure 
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APPENDIX D 


ANNEX 5 - TRANSMISSION REPLIES (ONLINE ASYNCHRONOUS PROTOCOL) 


$ 
CODE | MEANING 
| 


Block/message received and processed correctly. | 


logon and logoff replies, and of the 'retrieved frame' reply. 


i After ETB block: block received correctly; next block | 
expected | 
ii After ETX block: record received correctly and update | 
applied, next record expected. 

Note that '0' is also the first character of the successful 
I 
| 
! 


Block parity error(s) or block check fail: retransmitted 
block expected. If more than 4 such errors occur in succession,| 
the run is abandoned. t 


Record length error (ie different from 'record length' field 
or too big for input buffer); record is ignored. 


H 
| 4 
| 8 SYSTEM FULL | 
| 9 SYSTEM CLOSED. | 


Codes 0-1 are also used by the IP's computer in acknowledging blocks of a 
long record sent by Prestel (eg a 'retrieved frame'). 


APPENDIX E 
EDITING TERMINALS - TELECOM REQUIREMENTS 


The following sets out the requirements for such terminals to be acceptable 
for connection to the telephone network. 


1 The function of receiving Prestel shall be in accordance with the latest 
issue of the Viewdata Service Terminal Specification. 


2 Communication with the bulk update function of the computer shall be 

made via a British Telecom Datel Modem. For 1200/1200 working a Datel 600 installati 
to British Telecom Service Code 604/R/111 is likely to be suitable. Details of 

the modem are to be found in Technical Guide No 5(2). Protection requirements 

for the modem interface are to be found in Technical Guide No 26(2). 


3 Permission to attach the terminal eguipment to BT lines is given by 
British Telecom, Residential and Customer Services Department in accordance 
with Technical Guide 26, before the equipment is offered for sale or hire. 
Provisional permission should also be sought before development is started. 
Initial approaches with a view to connection to Prestel should be made to 
Prestel UK Marketing Division (Prestel 4.1.2). 


4 Data exchanges with the bulk update system shall be in accordance with 
the communication protocol given in Section 4. 


5 Technical enquiries concerning this specification should be referred 
to: 


Prestel 4.3.2 
Telephone House 
Temple Avenue 
LONDON 

EC4Y OHL 


Telephone: 01-583 9811 
6 References:- 


1 Viewdata Service Terminal Spec. Obtainable from Prestel 4.1.2 (see 
para 5 above). 


2 Technical Guide No 5 and No 26 obtainable from: 


British Telecom Marketing Executive 
RCS1.2.1.4 

Tenter House 

45 Moorfields 

LONDON 

EC2Y 9TH 
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